home *** CD-ROM | disk | FTP | other *** search
- Path: walrus.megabaud.fi!not-for-mail
- From: petrin@walrus.megabaud.fi (Petri Nordlund)
- Newsgroups: comp.sys.amiga.networking
- Subject: Re: Announce: AWeb 1.0 released!
- Date: 1 Apr 1996 17:15:07 +0300
- Organization: Megabaud Oy,Helsinki,Finland
- Message-ID: <4joodb$74d@walrus.megabaud.fi>
- NNTP-Posting-Host: walrus.megabaud.fi
-
- Michael van Elst (mlelstv@serpens.rhein.de) writes:
- >petrin@walrus.megabaud.fi (Petri Nordlund) writes:
- >>>That's something that you do not want. You want I/O, decoding and
- >>>rendering done concurrently and this means: at the same priority so
- >>>that they are timesliced.
- >
- >> I don't think that would be a good idea. You don't want image decoding
- >> to slow down rendering or response to GUI events. The magic word here
- >> is: threads.
- >
- >Where is the problem with decoding "slowing down" rendering ? The total
- >time is the same and concurrent operation will give a wanted visual
- >progress.
-
- If rendering just means drawing the decoded images, then it
- doesn't matter. But things like scrolling the document and
- opening other windows like hotlists etc. must not be slowed
- down by this.
-
- >I also didn't say anything about "response to GUI events". I/O means
- >network I/O. Sorry, if that was confusing.
-
- Ok, but why should rendering and decoding slow down network I/O?
-
- >> The best way to implement a WWW browser would be to use threads with
- >> fixed priorities.
- >
- >That's what AWeb does, although it runs the threads at the same fixed
- >priority of 0.
-
- Which doesn't make much sense because image decoding slows down
- everything else. You must remember that when the decoder task
- is running and you click on a gadget, the main task is not
- waked up immediately, Exec will let the decoder task run for
- a full quantum. The result is that the main task gets LESS
- than 50% of available CPU time to handle the GUI and user input.
-
- >> 3 rendering
- >> 2 decoder (small images)
- >> 1 decoder (large images)
- >
- >And this is something you do not need. Why should rendering stop decoding ?
-
- Let's say you are scrolling the display, why should decoding make
- scrolling slower?
-
- >> You can implement this on Amiga, but it doesn't work with dynamic
- >> priorities. If we would have threads on Amiga, there would be only
- >> one task to be scheduled.
- >
- >We have threads, thank you. And no, most systems schedule threads.
-
- We have LWPs (Light-Weight Processes), not real threads.
- We need user-level threads run as a single process. All threads
- share the same address space and are scheduled by a selectable
- thread-scheduler. Now we can only guess what would be good
- priorities for different LWPs, hoping that the main task is
- always run at priority 0.
-
- And if AT decides to bring Amiga OS and multitasking up-to-date,
- we need threads, either OS supported or as a 3rd party shared
- thread-library.
- --
- __
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~///~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Petri Nordlund __/// petrin@megabaud.fi
- ---------------------------------\XX/----------------------------------
-